1. Field of the Invention
The present invention relates to a method used in a service system, and more particularly, to a method of handling an execution result of a step in software and application control management object for a service system.
2. Description of the Prior Art
The Open Mobile Alliance (OMA) is founded to develop OMA specifications for mobile services to meet users' needs. Furthermore, the OMA specifications aim to provide the mobile services which are interoperable across geographic areas (e.g. countries), operators, service providers, networks, operation systems and mobile devices. In detail, the mobile services conforming to the OMA specifications can be used by the users without restriction to particular operators and service providers. The mobile services conforming to the OMA specifications are also bearer agnostic, i.e., the bearer that carries the mobile services can be a second generation (2G) mobile system such as GSM, EDGE or GPRS, or a third generation (3G) and beyond mobile system such as UMTS, LTE or LTE-Advanced. Further, the mobile services can be executed on an operation system such as Windows, Android or Linux operated on various mobile devices. Therefore, industries providing devices or the mobile services supporting the OMA specifications can benefit from a largely growing market enabled by interoperability of the mobile services. Besides, the users use the devices or the mobile services supporting the OMA specifications can also have a better experience due to the interoperability of the mobile services.
A device management (DM) protocol conforming to the OMA specifications is designed for management of mobile devices such as mobile phones, PDAs and palm top computers. The device management is intended to support the following typical uses: configuration of device for allowing changes to settings and parameters of the device, software upgrades for providing new software (e.g. applications and system software) and/or bug fixes to be loaded on the device, and fault management for reporting errors from the device, and/or querying about status of the device. In addition, the DM protocol defines a way according to which a DM client (e.g. mobile device) communicates with a DM server (e.g. network), and thereby the DM client can feedback a command, a status or a report to the DM server. Further, the DM server manages the DM client through a set of management objects in the DM client. The management object is conformed to the Software and Application Control Management Object (SACMO) specification, which aims to enable remote operations for software and application control in the client (It should be appreciated that the server and the client described below refer to the SACMO server and the SACMO client respectively), and is used for setting up parameters and operational functionality necessary for managing workflow object. More specifically, the server sends a management object tree to the client for setting up the workflow. If a “Start” operation corresponding to the management object tree in the client is triggered, then the client executes the workflow according to the management object tree until the workflow is completed or an error occurs.
A workflow is a sequence of steps which is conditionally executed. Each step can be an operation, process, command or other type of resource. Between steps, a condition is used to determinate the next step. Please refer to FIG. 1, which illustrates a schematic diagram of a workflow according to the prior art. In FIG. 1, a process (Process 1-3) is a basic unit for a specific operation execution, e.g. downloading software, checking memory size of the device. A process consists of a uniform resource identifier (URI) path which indicates the node of management object to execute and is indicated by a unique process identity. A step (Step A-C) is a basic unit of the workflow which consists of a process and information for the next steps. A step must have a process identity to indicate the process to execute. If a step is followed by another step, a nextstep subtree (NextStep B-C) is created. The nextstep subtree may contain multiple next steps. Each next step has a nextstep identity to indicate the following step and optionally a condition. The client checks the condition, if the condition is passed, and then the next step will be executed.
On the other hand, a transaction is an instance of a workflow execution. Server may retrieve result of the transaction execution from a “status” node under the management object tree for the workflow. As can be seen, in current design in SACMO, server retrieves the information in “Status” node under the management object tree to know the execution result of the transaction. However, there is no method to know the execution result of each step. Thus, the sever cannot know the progress of the transaction and cannot find out the cause if the transaction is executed unsuccessfully.